This forum is closed to new posts and
responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:
So you have an email and you want to find the hostname/ip address for the machine that generated the email?
If it was an smtp transmitted email then you would be able to check your notes log on the smtp server and you would see the ip address of the machine that connected to your smtp server to deposit the message. You can use message id or the FROM address (and posted date) as a string to search the log to find the mail routing event that relates.
If it's an email that's been generated by a notes client in your enterprise then the depositing client doesn't connect through smtp, it use notes rpc and so this info is not available. For internal mail, all you get is the depositing username appearing in the log (to the best of my knowledge). Perhaps ip becomess available with verbose logging switched on but I doubt it.
I've seen users with weird and wonderful personal/shared agents in their own mail files that can cause all sorts of weird scenarios. Switch to the user id and access the mailfile in designer to check for personal agents. Poorly considered mail rules in user mail files can also produce troublesome results.
If that user (mail principal) exists in your domain then they should have a person doc somewhere. And if they have a person doc then there will be a list of all the machines that they have ever used. You can find it in the last tab of their person doc.
If that user does not exist in your enterprise then you have to ask yourself how the email arrived through notes rpc. In this case, it's most likely being generated via an agent that has been signed with that persons id. You can use the notes log and message id to trace the email all the way back to the original dispatch server in your enterprise or else check the route servers field in email properties. On that first server you could then check for scheduled agents ("tell amgr show schedule"). If the agent is not scheduled then you would have to start looking within databases for likely agent candidates <sigh>.
This answer may not be very elegant but then neither is the solution to your problem. Alot of investigative work is often required when trouble-shooting dead mail.
Hope this has been of some use anyway.
Feedback response number WEBB8DXMVE created by ~Vera Xanlu on 02/10/2011